The Atari Compendium/The Atari Compendium (Toad Computers) (1994).iso/files/prgtools/programm.ing/progem.lzh/wind14.prf

Text File | 1987-06-23 | 21.6 KB | 438 lines

.!****************************************************************************
.!
.! ANTIC PUBLISHING INC., COPYRIGHT 1985.  REPRINTED BY PERMISSION.
.!
.! ** Professional GEM ** by Tim Oren
.!
.! Proff File by ST enthusiasts at
.! Case Western Reserve University
.! Cleveland, Ohio
.! uucp : decvax!cwruecmp!bammi
.! csnet: bammi@case
.! arpa : bammi%case@csnet-relay
.! compuserve: 71515,155
.!
.!****************************************************************************
.!
.!
.!****************************************************************************
.!
.!            Begin Part XIV
.!
.!****************************************************************************
.!
.PART XIV USER INTERFACES - Part 2
.PP
This  issue of ST PRO GEM (#14) continues the  discussion  of
user  interface  design which began in episode eight.   It  begins
where  we left off,  with a further treatment of the mode problem,
and  proceeds  into  topics such as visual  grammar  and  layered
interfaces.
.PP
     Note  that  there  is  no  download  for  this  column.   The
downloads  will return with the next issue,  a discussion of using
the  GEM DOS file system within a GEM application.   Specifically,
it  will include sample code for using the file selector,  the GEM
form_error  alerts,  and some utilities for manipulating file  and
path names.  There will also be a feedback section.  The following
two columns will be devoted to "graphics potpourri",  a collection
of  small  but useful GEM utilities such as  popup  menus,  string
editing, and source code for drag and rubber box operations.
.SH MODES AGAIN
If a program is modeless, it acts predictably,
which turns out to be very important.   On the other hand,  a good
definition  for  "modes"  is hard to find.   In  column  eight,  I
suggested  that  a  mode exists when you cannot  use  all  of  the
capabilities  of the program without performing some  intermediate
step.   If  this  is  less  than clear,  here  are  two  alternate
definitions offering different views of the problem.
.SH THE "TWO USER TEST"
Consider  the  following  thought
experiment:   Imagine  that  your ST (and GEM) had two  mice,  two
cursors,  and  two  users.   Could  they both effectively use  the
program at the same time?  If so, the application is modeless.  If
there are points where one user can be "locked out" by the actions
of  the other,  then a mode exists at that point.  Let's  consider
some examples of this test.
.PP
In any program which uses the GEM menu system, one user could
stop  the  other by touching a menu hotspot and dropping  a  menu.
This constitutes an inherent mode in the GEM architecture.
.PP
On  the  GEM Desktop,  two users could open windows and  view
files without interference.   However, as soon as one person tries
to delete a file (assuming the verify option is on),  the other is
brought  to  a halt as a dialog appears.   Thus,  we have found  a
modal dialog.
.PP
In  many "Paint-type" programs,  such as MacPaint,  PC Paint,
and  GEM Paint,  two artists could co-exist quite well,  utilizing
the  on-screen  palette  and tool  selection.   Of  course,  these
programs  also contain modal dialogs for such operations  as  file
and  brush  shape  selection.   In contrast,  consider  the  paint
program  DEGAS  for  the ST.   Here,  two artists could only  work
together as long as neither wanted to change tool or color.   Then
the  display  would have to be flipped to  the  selection  screen,
stopping the other user.  This is a mode in the DEGAS interface.
.PP
(By the way, this test is not just academic.  The grand-daddy
of all mouse based systems, NLS, demonstrated by Doug Englebart in
1968,  had  two  mice  and two users,  one of whom was  physically
remote.   Cooperative  techniques  such as this are still  largely
unexplored and unexploited.)
.SH ONE LINER
Here's  a  terse definition by  Jef  Raskin:  A
program is modeless if a given action has one and only one result.
Again, let's run a few examples.
.PP
The  menu  dropdowns are clearly modal  by  this  definition.
Before  the  menu was activated,  window control points  could  be
activated with a click.   However, when the dropdown is visible, a
click action is interpreted as a menu selection or a dismissal  of
the dropdown.   Similarly, dialogs are modal because the action of
moving  the mouse into the menu bar no longer causes the  dropdown
to appear.
.PP
I am typing this using the First Word editor program.  It has
a  nice desktop level box full of characters where I can click  to
get  symbols which the ST keyboard won't produce.   However,  if I
invoke  the  find or replace string dialog,  the  click-in-the-box
action  doesn't  work anymore.   This is a mode in the First  Word
interface.
.PP
Finally, consider an "old style" menu program, the kind where
you  type in the number of the desired action from a list.   Since
the  number  "2" might mean "Insert the record" in one  menu,  and
"Purge  the file" in another,  such a program is clearly modal  by
Raskin's definition.
.PP
These  three definitions say almost the same thing,  but from
different  viewpoints.   Depending  on the situation,  one or  the
other  may  be more intuitive for you.   The goal of this type  of
analysis  is to root out unnecessary modes,  and to make sure that
those  which remain only appear when requested by the user,  offer
some visual cue such as a rubber line or standard dialog box,  and
are used consistently throughout the application.
.SH PREDICTABILITY FOREVER AND EVER AND EVER
As  Raskin's
definition  makes  clear,  when the modes go away,  the  interface
becomes  predictable.   Predictability  leads to the formation  of
habits   of   use.     Habits  reduce  "think  time"  and   become
progressively faster due to the Power Law of Practice discussed in
column eight.  This is exactly what we want!
.PP
There is another benefit of predictability.   A habit learned
in  one  part  of a program with a  consistent  interface  can  be
transferred  and  used elsewhere in the application.   If  several
programs share the same style of interface, the same habits can be
used across a complete set of products.  Learning time for the new
functions becomes shorter,  and the user is more likely to use the
new feature.
.SH IS A BOGEYMAN!
Most  casual  users are  scared  silly  of
computers  and programs.   (If you have any doubt,  eavesdrop on a
secretary with a new word processor,  or the doctor's receptionist
coping with an insurance data entry program.)  In most cases, they
have  a  right to be frightened.   Even  experienced  programmers,
prone  to  toss  the manuals and hack  away,  know  that  moderate
paranoia  is  the best way to deal with an unknown  program.   How
must this feel to someone whose ability to perform (or lose) their
job depends on an unpredictable (aha!) black box.
.PP
So here's another way in which predictability works.   But to
produce  a truly fearless user,  we need other qualities as  well.
One  is robustness,  meaning that the program will not crash given
normal or even bizarre actions by the user.   Another is feedback,
which shuts off invalid options,  reinforces correct actions,  and
gives  reassurance  that  an  operation  is  proceeding  normally.
Finally, we need forgiveness, in the form of inverse operations or
Undo options, when the inevitable mistake is made.
.PP
The  ultimate  goal is make the program  discoverable.   This
means  the user should be able to safely "wing it" after  a  short
session  with  the application and its interface.   This  practice
ought to be considered the norm anyway, since the manual is always
across  the office or missing when an esoteric and  half-forgotten
feature  is  needed.   If it is possible to muddle through such  a
situation  by  trial  and  error,   without  causing  damage,  the
immediate  problem  will  be  solved,   and  the  user  will  gain
confidence.
.SH GOOD GRAMMAR OR...
So exactly what are these habits that are
supposed  to be so helpful?   One of the most useful patterns is a
consistent  command  grammar  for the  program.   This  may  sound
strange,   since   we  have  supposedly  abandoned  command   line
interfaces  in the graphics world,  but in fact,  the same type of
rules apply.   For instance, in the world of A> we might issue the
command:
.br
.sp
.ce
copy a:foobar.txt b:
.PP
By  analogy  to  Englist grammar,  this command contains  a  verb,
"copy",  a  file  as  subject:  "a:foobar.txt",  and a location as
an object: "b:".  The equivalent GEM Desktop operation is:
.BO
- Move mouse to foobar.txt icon in a: window
.EO
.BO
- Press mouse button
.EO
.BO
- Move mouse to b: icon
.EO
.BO
- Release mouse button
.EO
.PP
The  operation  can be described as a  select-drag-drop  sequence,
with  the select designating the subject file,  the drag  denoting
the  operation  (copy),  and the location of the drop showing  the
object.   A  grammar still exists,  but its "terminal symbols" are
composed  of  mouse  actions interpreted in  the  context  of  the
current screen display, rather than typed characters.
.PP
One  useful way to analyze simple grammars,  including  those
used  as  command  languages,  is to separate  them  into  prefix,
postfix,  and infix forms.   In a prefix grammer, the operation to
be  performed precedes its operands,  that is,  its subject(s) and
object(s).   The  DOS copy command given above is an example of  a
prefix  command.   LISP  is  an example of a language  which  uses
prefix specification for its commands.
.PP
Postfix grammars specify the action after all of the operands
have been given.   This command pattern is familiar to many as the
way  in  which  Hewlett-Packard calculators  work.   FORTH  is  an
example of a language which uses a postfix grammar.
.PP
Infix  notation  places the verb,  or operator,  between  its
subject and object.   Conventional algebraic notation is infix, as
are most computer languages such as C or PASCAL.   The example GEM
command  given  above  is also infix,  since the  selection  of  a
subject  file  preceded  the action,  which was  followed  by  the
designation of an object.
.PP
The  "standard" GEM command grammar,  as used in the products
produced  by Digital Research,  is in fact infix.   This is not to
say that GEM enforces such a convention,  or that it is rigorously
followed.  However, when there is no pressing reason for a change,
adoption  of an infix command grammar will make  your  application
feel most like others which users may have seen.
.PP
The general problem of specifying a graphic command  language
can be difficult, but much of the problem has already been handled
on the ST.   Part of the solution is by constraint:  the input and
output hardware of the ST are predefined,  so most developers will
not  need  to  worry about choosing a pointing  device  or  screen
resolution.   The  other part of the standard solution is the  GEM
convention for mouse usage.  I am going to review these rules, and
then describe of the situations in which they have been bent,  and
finally  some alternate approaches which may prove useful to  some
developers.
.SH SPECIFYING A SUBJECT
There are really two sets of methods
for  designating what is to be affected by an operation.   One set
is  used when distinct objects are to be affected.   Examples  are
file and disk icons in the Desktop and trees in the RCS.   Another
set of designation methods is used when continuous material,  such
as text or bit images, is being handled.
.PP
When dealing with objects, a single mouse click (down and up)
over the object selects it.   The application should show that the
selection  has occurred by changing the appearance of the  object.
The  most  common  methods are inverting the  object,  or  drawing
"handles" around it.
.PP
Many   operations   allow  "plural",   or  multiple   object,
selections.  The GEM convention is that a click on an object while
the  shift key is held down extends the selection by  adding  that
object.   If the shift-clicked object was already selected,  it is
deleted from the selection list.
.PP
Another  way to select multiple objects is to use  a  "rubber
box"  to enclose them.   This operation begins with drag on a part
of  the  view where no object is present.   The  application  then
animates a rubber box on the screen as long as the mouse button is
held  down.   When the button is released,  all objects within the
current extent of the box are selected.   A shift-drag combination
could be used to add the objects to an existing selection list.
.PP
Selecting  part of a text or bit plane display is  also  done
with a rubber box.   Since there are no "objects" in the view, any
mouse  drag  is  interpreted  as  the  beginning  of  a  selection
operation.   In  the  simplest  case,  a bit plane,  the rectangle
within the box when the button is released is the selected extent.
.PP
When  the  underlying data has structure,  such as words  and
lines  of  text,  the display should reflect this fact during  the
selection  operation.   Typically,  text selection is indicated by
inversion  of  the  characters  rather than  a  rubber  box.   The
selection  extends  along the starting line so long as  the  mouse
stays  within the line.   If the mouse move off the starting  text
line, the implied selection is all characters between the starting
character  and the character currently under the mouse,  which  is
not necessarily a rectangular area.
.PP
An  extended  "plural"  selection may be  supported  in  text
editing.   The  use of the shift key is also conventional in  this
application.
.SH ACTION
With the subject designated, the user can now choose
an operation.   In many cases,  this will be picked from the menu,
in  which  case  the  entire  command  is  complete.    Some  menu
selections will lead to dialogs,  in which the interaction methods
are  regulated  by  the GEM form manager.   When  the  command  is
completed,  it  is  often  helpful if the application  leaves  the
objects  (or areas) selected and ready for another  operation.   A
single click away from any object is interpreted as cancelling the
selections.
.PP
Many  operations  are indicated by gestures  on  the  screen.
Usually,   this  is  some  variant  of  a  drag  operation.    The
interpretation of the gesture may depend on the type and  location
of the selected subject,  which part of it is under the mouse, and
in what location the drag terminates.
.PP
"Handles"  are small boxes or dot displayed around an  object
when it is selected.   A drag beginning with the mouse on a handle
is  usually  interpreted  as  a resizing  operation,  if  this  is
appropriate.   The  pointing  finger  mouse form is  displayed  to
indicate  the operation in progress,  and a rubber version of  the
object  is animated on the screen to show the user the  result  if
the  button  were released.   In some cases,  where an  underlying
"snap"  grid  exists,  the  animated  object may  change  size  in
discrete steps.
.PP
Dragging  a non-handle area of a selected object  is  usually
interpreted  as  the  beginning  of  a  move  function.   In  most
applications,  a  move  of a single object may be started  without
pre-selection.   Simply  beginning the drag on the object is taken
to imply selection.  The spread hand, or "grabber", mouse form  is
typically displayed during a drag operation.
.PP
Dragging  may  denote copying or movement,  or  more  complex
functions such as instantiation or generalization.   The operation
implied by movement on the screen will differ among  applications,
and  often  within  the  same  application,  depending  on  target
location.   This  target is the recipient of the command's action,
or its object, in an English grammar sense.
.PP
For  example,  a  drag from window to window in  the  Desktop
denotes a copy.   On the other hand, dragging the same icon to the
trashcan  deletes it completely.   Dragging an object from the RCS
partbox  to the editing view creates a new copy of that  prototype
object.   Dragging  the  same object within the edit  view  simply
changes its placement.
.PP
There   are  some  mouse  actions  which   are   conventional
"abbreviations".   A  double click on an object is interpreted  as
both a selection and an action.   Usually, the double click action
is the same as the Open entry in the "File" menu.
.PP
When  the  usual interpretation of a drag is  movement,  then
shift-drag  may be used as an enhanced varient  implying  copying.
For  instance,  shift-dragging  an object within the  RCS  editing
window  makes  a  copy of the object and places it  in  the  final
location.
.PP
To return to the beginning of this discussion, the reason for
adopting  these conventional usages is to build an interface  that
promotes  habits.   Particularly,  a  standard grammar for  giving
commands helps answer the question "What comes next?".   It breaks
the user's actions into logical phrases,  or chunks,  which may be
thought of a whole, rather than one action at a time.
.SH DIFFERENT FOLKS, DIFFERENT STROKES
.PP
There  are  always
exceptions to a rule,  or so it seems.   In this case, consistency
of   the  interface  grammar  is  sometimes  traded  off   against
consistency of metaphor,  preservation of screen space,  and "fast
path" methods for experts.
.PP
One example is the use of "tools" in Paint and Draw programs.
In  such  programs,  an  initial  click is made on  a  tool  icon,
denoting the operation to be applied to all following  selections.
This is an prefix style of grammar,  and stands in contrast to the
usual  method  of selecting subject object(s) first.   Because  of
this contrast,  it is sometimes called "moding the cursor".   (Try
applying the tests above to be sure it really is a mode.)
.PP
In  these  cases,  there  are two reasons for  accepting  the
nonstandard  method.   The first is consistency of metaphor.   The
"user model" portrayed in the programs is an artist's work  table,
with  tools,  palette,  and  so  on.   The cursor moding action is
equivalent  to  picking up a working tool.   The second reason  is
speed.   In a Paint program,  the "canvas" is often modified,  and
speed  in  creating or changing the bits is  important.   In  more
object  oriented applications such as Desktop or RCS,  the objects
are more persistent.   Speed is then more essential when adding or
changing properties of the objects.
.PP
When  command  styles  are mixed in this  fashion,  you  must
design very carefully to avoid conflicts or apparent  side-effects
in  the  command language.   For example,  in GEM Draw picking  an
action from the Edit menu cancels the current cursor mode  without
warning.   Confusion  from  such side-effects may cancel  out  the
benefits of the mixed grammar.
.PP
The  subject  of command speed  deserves  further  attention.
While  the  novice approaching a program needs  full  feedback,  a
person who uses it day in and day out will learn the program,  and
want  faster  ways  to get the job done,  even if  they  are  more
arcane.  The gives rise to a "layered" style of interface.
.PP
A layered interface is designed so that the visual grammar is
obvious,  as  we  have discussed.   However, there are one or more
sets of "accelerators" built into the program, which may be harder
to find but faster to use.  One example is condensed mouse actions
such  as the double-click.   For instance,  attempting to select a
block  of text which extends beyond a window is  impossible  using
the  basic metaphor.   The novice will simply do the operation  in
pieces.   A  layered interface might put a less obvious Mark Begin
and  Mark End option in the menus.   Another way is to take a drag
which  extends outside the window as a request to begin  scrolling
in that direction, while extending the current selection.
.PP
One  of  the most common and useful  accelerator  methods  is
function  keys.   Using  this approach,  single key equivalents to
actions are listed in the menu.   Striking this key when an object
is  selected  will cause the action to occur.   Note that this  is
most  useful if some keyboard driven method of  object  selection,
such as tabbing, is also available.  Otherwise, the time switching
from  the  mouse,  used to select the object,  to the keyboard for
command input, may well cancel any advantage.
.PP
Finally,  radical  departures  from the GEM metaphor  may  be
useful when attempting to replicate the look of another system, or
trying  to  meet severe constraints,  such as display space.   One
example  would  be discarding the standard GEM menus in  favor  of
"popup"  menus which appear next to the current mouse position  in
response  to  a click on the second button.   This method has  the
advantage  of preserving the menu space at the top of the  screen,
and  is potentially faster because the menu appears right next  to
the  current mouse position.   The drawbacks are lack of a  visual
cue for naive users trying to find the commands,  and the need for
custom coding to build the popups.
.SH MORE TO COME
We have reached the end of the second sermon
on  user  interface.   In a future column,  I will look at "higher
level"  topics  relating to the design of the  application's  user
metaphor.   These  include  issues of object  orientation,  direct
manipulation,   and  the  construction  of  microworlds.   In  the
meantime,  several  of  the  more practical columns  will  present
implementions  of  techniques such as accelarator keys  and  popup
menus which I have discussed this time.
.PP
THANKS AND APOLOGIES to the following people whose public and
published   remarks  have  formed  part  of  the  basis  of   this
discussion:  Jef Raskin, Bill Buxton, Adele Goldberg, James Foley,
and Ben Schneidermann.  As always, any errors are my own.
.!
.!
.!*****************************************************************************
.!*                                          *
.!*                End Part XIV                      *
.!*                                          *
.!*****************************************************************************